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1.  SCOPE 

1.1.  Identification.  This  Module  Specification  volume  establishes  the  requirements  for 
the  Visual  Module  of  the  Advanced  Rotary  Wing  Aircraft  (ARWA)  device.  This  volume  is 
one  of  three  volumes  of  a  System  Specification  defining  an  Advanced  Rotary  Wing  Aircraft 
Simulator  System  (ARWA  SS)  for  tactical  combined  forces  aircrew  simulation  devices. 
Volume  I  of  this  specification  contains  system  level  requirements  which  include  those 
pertaining  to  system  stricture,  communication  architecture,  network  interface  performance, 
system  diagnostic  and  test,  programming  language  applicability,  adaptability  and 
expandability. 

1 .2.  Purpose.  This  Module  Specification  volume  defines  the  requirements  of  the  Visual 
Module  for  one  ARWA  device.  This  specification  contains  descriptions  of  the  functions 
performed  within  the  module,  communication  interface  requirements,  module  performance 
requirements,  module  diagnostic  and  test  requirements  and  expandability  and  adaptability 
requirements  as  applicable  to  the  Visual  Module. 

1.3.  Introduction.  The  principal  purpose  of  the  Visual  Module  is  to  simulate  out- the- 
window  and  sensor  imagery  and  to  display  this  imagery  to  the  crew  members  of  an 
ARWA  device.  In  addition,  this  module  provides  for  the  ARWA  device  the  information 
pertaining  to  relationship  between  visual  data  base  models  and  geographic  positions.  In 
this  specification  the  role  of  the  Visual  Module  is  partitioned  into  the  following  functional 
areas: 


a)  ARWA  Global  Bus  Interface  Function  which  provides  the  physical  and  logical 
connection  of  the  Visual  Module  with  the  other  mc^ules  of  the  ARWA  device. 

b)  Visual  System  Controller  Function  which  coordinates  the  operations  of  all  the 
other  functions  in  the  module. 

c)  Image  Generation  Function  which  produces  the  video  imagery  in  response  to  the 
controls  of  the  Visual  System  Controller. 

d)  Display  Device  Function  which  produces  the  visible  displayed  images  from  the 
video  inputs. 

e)  Intervisibility  Function  which  provides  the  interrelational  information  of  the  data 
base  models  and  geographic  positions. 

f)  Head  Tracker  Function  which  reports  the  instantaneous  position  and  orientation 
of  the  helmets  of  the  crew  members  within  the  cockpit. 

f)  Data  Base  Storage  Function  which  provides  immediate  access  to  the  visual  data 
base. 

This  specification  establishes  the  functional  requirements  for  each  of  these  functions  and 
their  interfaces. 

2.  APPLICABLE  DOCUMENTS 

2. 1 .  Government  Documents.  The  government  documents  which  are  applicable  to  the 
entire  ARWA  SS  are  listed  in  Volume  I  of  this  specification.  The  following  additional 
government  documents  are  applicable  to  the  Visual  Module:  None. 
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2.2.  Non-Government  Documents.  The  non-government  documents  which  are 
applicable  to  the  entire  ARWA  SS  are  listed  in  Volume  I  of  this  specification.  The 
foUowing  additional  non-government  documents  are  applicable  to  the  Vinial  Module: 

ADST  Step  One  Technical  Report  (Draft),  Boeing  Defense  and  Space  Group,  Huntsville, 
AL,  7  August  1991 

AH-64A  APACHE  AIRCRAFT  COCKPIT  CONKGURATION  TECHNICAL  REPORT 
(Draft),  Version  1.2,  DSC  Corporation,  Alexandria,  VA,  2  August  1991 

AH-64C/D  APACHE  AIRCRAFT  COCKPIT  CONFIGURATION  TECHNICAL 
REPORT  (Draft),  Version  1.0,  DSC  Corporation,  Alexandria,  VA,  2  August  1991 

DATA  TO  SUPPORT  SIMULATION  OF  RWA  VISUAL  SYSTEMS,  Version  1.1,  DSC 
Corporation,  Alexandria,  VA,  2  August  1991 

PRELIMINARY  DATA  OF  MAGNIFICATIONS  OF  DISPLAYED  RWA  SENSOR 
IMAGERY,  DSC  Corporation,  Alexandria,  VA,  9  August  1991 

3.  REQUIREMENTS 

3.1.  Module  Definition. 

3.1.1.  Missions.  The  mission  of  the  Visual  Module  is  to  provide  imagery  of  sufficient 
fidelity  to  support  the  mission  requirements  as  described  in  Paragraph  3.1.1  of  Volume  I  of 
this  specification. 

3.1.2.  Threat-  Not  applicable. 

3.1.3.  Module  Modes  and  States.  The  Visual  Module  shall  operate  within  the  various 
modes  arid  states  as  defined  in  Volume  I,  Paragraph  3.1.3.  The  Visual  Module  shall  also 
function  in  accordance  with  the  mode  and  state  transition  requirements  define  in  Volume  I, 
Paragraph  3.1.3,  and  diagrammed  in  the  following  figures:  Figures  3.1.3.3-1  and  3.1.3.3- 


3. 1.3.1  Module  Mode.  This  mode  has  two  states:  Start-up  Initialization  and  Stand¬ 
alone. 

3. 1.3. 1.1  Start-up  Initialization.  Upon  power  up,  each  component  of  the  Visual 
Module,  as  appropriate,  shall  execute  internally  stored  (read  only  memory  (ROM))  boot- 
pipgrams  to  initialize  communication  paths  within  the  Visual  Module  and  between  the 
Visual  Module  and  the  ARWA  Network  (FDDI  Network).  The  Visual  System  Controller 
(VSC)  Function  shall  then  direct  the  loading  of  the  various  initialization  and  diagnostic 
programs:  to  initialize  each  Visual  Module  component  to  a  state  in  which  to  receive 
simulation  sp^ific  application  programs;  to  perform  morning  readiness  diagnostics;  and  to 
report  pass/fail  availability  of  the  Visual  Module  (to  the  Simulation  Manager  via  the  ARWA 
Network). 

B^d  upon  commands  from  the  Simulation  Master  via  the  ARWA  Network  (FDDI),  the 
Visual  Module  either  transitions  to  System  Mode  or  enters  the  stand-alone  state  of  Module 
Mode. 

3. 1.3. 1.2  Stand-Alone  State.  The  initial  transition  to  stand-alone  mode  is 
accompanied  by  the  retrieval,  loading  and  execution  of  the  VSC  Function  program  to 
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control  the  stand-alone  state.  In  this  state  the  Visual  Module  shall  respond  to  controls  and 
data  which  are  received  via  the  ARWA  Network  (FDDI).  These  controls  and  data  can 
originate  with  the  Simulation  Manager  or  with  any  user  station  on  the  network.  The 
functional  requirements  of  this  state  are  described  with  the  VSC  Function  requirements. 

3. 1.3.2  System  Mode.  The  initial  transition  to  this  mode  is  accompanied  by  the 
retrieval,  loading  and  execution  of  any  programs  required  to  establish  the  Visual  Module 
and  ARWA  Global  bus  interface.  In  this  mode  the  Visual  Module  awaits  mode  transition 
commands  on  the  ARWA  Global  bus.  From  the  System  Mode,  the  Visual  Module  can 
transition  to  the  Remote  Controlled  Diagnostic  Mode,  the  Simulation  Mode  or  the  Shut 
Down  Mode. 

3. 1.3.3  Simulation  Mode.  Figure  3. 1.3.3- 1  depicts  the  simulation  mode.  Figure 
3.1. 3.3-2  depicts  the  state  transitions  of  this  mode. 
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3. 1 .3.3. 1  Initialization  State.  Upon  transition  to  Simulation  Mode,  the  Visual  Module 
is  in  this  state.  When  entering  this  state  from  System  Mode,  the  Visual  Module  shall 
retrieve  (over  FDDI  from  the  software  (SW)  Maintenance  station),  load  and  execute  the 
simulation  programs  for  the  various  Visual  Module  components.  When  all  components  are 
executing  their  programs,  the  module  is  ready  to  respond  to  a  state  transition  command  to 
enter  the  Alignment  State  or  return  to  the  System  Mode. 

3. 1 .3.3.2  Alignment  State.  Upon  entry  into  this  state,  the  Visual  Module  shall  retrieve 
the  relevant  data  definition  files  from  the  Software  and  Data  Base  Maintenance  stations.  If 
the  appropriate  data  base  Hies  are  not  resident  in  the  Visual  Module  data  base  storage 
devices  (Ae  wrong  or  incorrect  version  of  the  data  base  is  loaded),  the  Visual  System 
Controller  Function  shall  coordinate  the  loading  of  the  appropriate  data  bases  over  the 
Intervisibility  Servers  (FDDI)  Network.  The  VSC  shall  then  proceed  to  initialize  the  other 
Visual  Module  components  as  appropriate  to  the  conditions  specified  in  the  data  deHnition 
files.  These  conditions  shall  include  the  terrain  data  base  position  of  the  ownship  and  the 
initial  modes  of  the  sensors;  and  therefore,  in  this  state,  the  terrain  data  appropriate  for  the 
position  of  the  ownship  can  be  retrieved  and  loaded  into  the  memories  of  the  image 
generator. 

When  all  data  loading  and  other  Visual  Module  initialization  is  completed,  a  completion 
message  is  communicated  over  the  ARWA  Global  bus  and  the  Visual  Module  stand  ready 
for  a  transition  command  to  the  Total  Freeze  State. 
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3. 1 .3.3.3  Total  Freeze  State.  In  this  state  the  components  of  this  Visual  Module  are 
executing  the  simulation  programs;  however,  no  internal  parameters,  as  ownship  position, 
nor  other  aspects  of  image  content,  are  being  updated. 

3. 1 .3.3.4  Run  State.  In  this  state  the  Visual  Module  is  producirig  images,  as  well  as 
Intervisibility  Function  results,  based  on  control  parameters  received  via  the  ARWA  Global 
bus  and  from  the  Helmet  Tracker  Function. 

3. 1.3.4  Remote  Controlled  Diagnostic  Mo<k.  The  Visual  Module  shall  support  this 
mode  by  responding  as  appropriate  to  the  two  self-test  commands  which  are  received  via 
the  ARWA  Global  bus.  The  Visual  Module's  response  to  these  two  self-tests  is 
coordinated  by  the  VSC  Function  (Refer  to  the  Visual  System  Diagnostics  paragraph  of  the 
VSC  Function  Requirements  for  a  description  of  the  processing  of  the  two-self  tests). 

3. 1.3.5  Shut  Down  Mode.  The  Visual  Module  has  no  required  actions  in  this 
mode.  When  the  command  to  transition  into  Shut  Down  Mode  (from  System  Mode)  is 
received,  the  Visual  Module  shall  transition  into  Module  Mode. 

3.1.4.  Module  Functions.  A  top-level  diagram  of  the  functions  composing  this  module 
with  their  interrelationships  and  their  extern^  interfaces  is  given  in  Figure  3. 1.4-1. 


RRUIR  6L0RRL  RUS 


Figure  3. 1 .4- 1  Visual  Module  Block  Diagram 


3.1.4.1.  ARWA  Global  Bus  Interface  Function. 

3. 1.4. 1.1.  Purpo.se.  This  interface  provides  the  physical  and  logical  linkage  of  the 
Visual  Module  and  the  remainder  of  the  ARWA  device.  The  role  of  this  interface  in  the 
device  is  fully  described  in  Paragraph  3.1.7  of  Volume  I  of  this  specification.  For  the 
Visual  Module  this  interface  function  captures  commands  and  data  on  the  ARW  A  Global 
Bus  which  are  addressed  to  the  Visual  Module  and  makes  these  data  available  to  the 
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functions  of  the  Visual  Module  in  a  format  which  these  functions  can  recognize  (e.g., 
ARWA  Global  Bus  (ModSim)  headers  and  trailers  are  removed). 

3. 1 .4. 1 .2.  Physical  Characteristics.  The  physical  realization  of  the  function  is  the  Bus 
Interface  Unit  (BIU)  which  is  fully  described  in  Paragraph  3.1.7  of  Volume  I  of  this 
specification. 

3. 1 .4. 1 .3.  Performance  Characteristics.  The  functional  requirements  of  the  BIU  are 
specified  in  Paragraph  3.1.7  of  Volume  I  of  this  specification. 

3. 1.4.2.  Visual  System  Controller  Function. 

3.1. 4.2.1.  Purpose.  The  Visual  System  Controller  (VSC)  function  provides  the 
(logical)  interface  between  this  module  and  the  ARWA  Global  Bus  (via  the  BIU)  and  the 
ARWA  Network  Bus.  Thus,  this  function  controls  the  modes  and  states  of  the  module, 
coordinates  module  diagnostics,  provides  start-up  and  initialization  service  to  all 
components  of  this  module,  controls  the  visual  system  processing  load  and  controls  the 
image  generation  function  by  providing  the  commands  and  appropriate  model  data 
necessary  to  product  the  video  images  as  indicated  by  the  controls  via  ^e  ARWA  Global 
bus. 

The  VSC  Function  also  includes  the  control  of  the  Intervisibility  Server  Function. 

When  the  Visual  Module  is  not  integrated  with  ARWA  Global  Bus,  the  VSC  Function 
provides  a  resource  to  generate  ARWA  Global  Bus  commands  and  data  to  exercise  most  of 
the  operations  of  this  module.  This  function  shall  be  able  to  respond  to  commands  and  data 
received  via  the  ARWA  Network  from  any  user  workstation  on  the  network. 

3.1.4.2.2.  Physical  Characteristics.  The  principal  functionality  of  the  VSC  is 
Implemented  in  applications  programs  which  can  reside  in  a  stand-alone  computational 
system  or  on  one  or  more  microprocessor  cards  residing  with  other  physical  component  of 
the  system  (e.g.,  in  the  image  generator  or  shared  with  the  BIU  card).  The  VSC  shall 
support  the  intermodular  interfaces  of  the  Visual  System  Module  as  described  in  Section 
3.7. 

3.1.4.2.3.  Performance  Characteristics. 

3. 1. 4.2.3. 1.  Start-up  Initialization.  As  part  of  power-up  and  after  shut-down,  this 
function  shall  retrieve  an  iititialization  load  which  shall  run  diagnostic  tests  necessary  to 
determine  the  readiness  of  all  visual  system  components.  If  all  components  are  ready,  a 
ready  signal  shall  be  generated;  otherwise,  a  failure  report  shall  be  generated  indicating 
which  components  are  not  available.  During  this  initialization  phase,  this  function  shaU 
establish  communication  with  the  ARWA  Global  Bus  (via  the  BIU)  if  Module  Stand-along 
operations  are  not  desired. 

3. 1 .4.2.3. 2.  Simulation  Initialization.  As  commanded  over  the  ARWA-Global  bus,  the 
VSC  Function  shall  retrieve,  load  and  start  executing  the  appropriate  simulation  program 
load  which  is  stored  in  the  Software  Maintenance  Station.  This  simulation  program  shall 
establish  its  own  commurucations  with  the  ARWA  Global  Bus  (via  the  BIU).  The 
simulation  program  shall  retrieve  over  the  ARWA  Network  mission  specification  and  initial 
condition  Hies  and  shall  provide  the  initial  code  and  data  loading  based  on  the  contents  of 
these  mission  and  initial  conditions.  Upon  completion  of  this  initialization  and  data  loading 
process,  the  visual  module  is  ready  for  the  simulation  mission.  The  VSC  Function  shall 
communicate  mission  readiness  over  the  ARWA  Global  Bus. 
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3. 1 .4.2.3. 3.  Visual  System  Diagnostics.  The  VSC  Function  shall  provide  three  levels  of 
diagnostic  support:  Start-up  readiness  testing  as  described  in  Start-up  Initialization;  fault 
isolation  diagnostics  for  the  hardware  components  comprising  the  visual  module;  and 
remote  diagnostics  which  consist  of  the  two  capabilities  described  below. 

For  remote  diagnostics,  the  VSC  Function  shall  coordinate  the  echo-back  test  in  which  the 
contents  of  the  echo-back  test  request  are  returned  over  the  ARWA  Global  Bus.  The  VSC 
shall  also  support  the  equipment  test  which  requires  that  each  piece  of  equipment  in  the 
visual  module  be  polled  for  readiness  and  a  collective  pass/fail  status  message  be  returned 
over  the  ARWA  Global  Bus  be  returned  indicating  the  status  of  each  of  the  pieces  of 
equipment 

Fault  isolation  diagnostics  shall  be  controlled  in  stand-alone  state  of  Module  Mode  by 
means  of  commands  received  via  the  ARWA  Network. 

3.1.4.2.3.4.  System  Freeze.  The  VSC  Function  shall  support  the  total  freeze  state  ( 
which  is  entered  after  simulation  initialization  is  complete).  In  this  state  all  visual  module 
updates  of  positions,  attitudes,  animations,  and  other  time  variable  parameters  cease.  It 
shall  be  possible  to  select  subsets  of  these  variable  parameters  for  partial  freezes  in  states 
other  than  total  freeze  (e.g.,  the  freezing  of  positional  updates  of  the  moving  models  and 
c  wnship  but  not  the  attitude  updates  of  the  head  tracker).  Subsets  of  the  time  variable 
parameters  shall  be  included  in  the  partial  freezes. 

3.1.4.2.3.5.  Security  Shutdown.  The  VSC  Function  shall  support  the  security 
shutdown  requirements  by  taking  no  action  when  in  the  Security  Shutdown  Mode.  Upon 
being  commanded  to  enter  this  mode,  the  VSC  Function  shall  immediately  enter  into 
Module  Mode  and  commence  Stait-up  Initialization 

3.1.4.2.3.6.  Dynamic  Data  Interface  Control.  There  are  two  sources  of  external  dynamic 
data  entering  the  VSC  Function:  The  data  from  the  ARWA  Global  Bus  via  the  BIU  and  the 
data  from  the  head  tracking  function. 

The  VSC  shall  provide  the  interface  handlers  for  the  BIU  and  the  drivers  for  Head  Tracker. 

All  dynamic  position  and  attitude  data  received  from  either  of  these  two  interfaces  shall  be 
both  converted  into  coordinate  systems  required  by  the  Visual  Module  and  shall  be 
extrapolated  to  account  for  both  lags  introduced  by  system  and  network  transmission  and 
by  the  asynchronous  operation  of  the  different  clocks  within  the  ARWA  device. 
Conversion  to  a  visual  system  data  base  coordinate  system  shall  be  performed,  when 
required,  due  to  the  use  of  spherical  (lat,  long,  altitude  above  Earth  center  or  above  mean 
sea  level)  or  other  coordinate  system  data  representations  exterior  to  the  Visual  Module. 

3. 1 .4.2.3. 7.  Stand- Aone  Operations.  The  VSC  Function  shall  support  the  stand-alone 
state  of  the  Module  mode  with  the  capability  to  generate  commands  and  data  which  emulate: 
a)  Aose  received  over  Ae  ARWA  Global  Bus  during  Simulation  Mode  but  in  Ae  format 
which  the  VSC  receives  from  Ae  BIU;  and  b)  those  received  from  Ae  head  tracker 
function. 

Durmg  stand-alone  operations,  Ae  VSC  Function  shall  respond  to  commands  and  data 
received  via  Ae  ARWA  Network  (FDDI).  These  commands  and  data  can  be  generated  at 
any  user  workstation  on  Ae  netwoik,  including  Ae  Simulation  Manager. 
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In  this  state,  the  BIU  is  not  connected  to  the  ARWA  Global  Bus  but  the  VSC  shall  received 
the  emulated  data  and  commands  as  though  this  connection  were  present.  In  the  stand¬ 
alone  state,  the  VSC  Function  shall  be  able  to  generate  the  post-BIU  ARWA  Global 
Commands  and  data  necessary  to  test  and  demonstrate  all  aspects  of  the  Visual  Module's 
operations  including:  the  contents  of  mission  parameter  files,  all  state  and  mode  transitions 
commands,  all  sensor  controls,  all  ownship  and  moving  models  controls,  all  diagnostic  test 
commands  and  requests  for  Intervisibility  Function  resources. 

In  this  stand-alone  state,  an  operator  shall  be  able  to  place  the  ownship  and  some  moving 
models  in  the  gaming  area  widi  any  positions  and  attitudes  and  with  continuous  updating  of 
these  parameters.  The  operator  shall  also  be  able  to  specify  head  position  and  attitude. 

In  this  state,  the  VSC  Function  shall  coordinate  fault  isolation  diagnostics  via  controls 
received  on  Ae  FDDI  network. 

3.I.4.2.3.8.  Image  Generation  Control.  The  VSC  Function  shall  generate  and  transfer  to 
one  or  more  image  generators  full  instructions  for  Ae  generation  of  the  two  sensor  images. 

The  generation  of  instructions  and  Aeir  transfer  shall  be  accomplished  so  Aat  Ae  total 
transport  delay  from  receipt  of  the  position  and  attitude  data  by  Ae  VSC  to  Ae  start  of 
display  of  Ae  image  incorporating  Aese  data  does  not  add  more  than  10%  to  Ae  allowable 
transport  delays  specified  by  Ae  Image  Generation  Function. 

Similarly,  Ae  time  to  respond  to  changes  of  sensor  mode,  field  of  view  (FOV)  and  time-of- 
day  (TOD)  shall  not  be  more  Aan  10%  of  Aat  speciHed  by  Ae  Image  Generation  function. 
Thk  time  mcludes  any  needed  reloaAng  of  color  and/or  sensor  intensity  daA  tables. 

The  image  generation  controls  shall  mclude: 

a)  The  update  of  Ae  position,  attitude  and  geometry  of  Ae  two  sensor  and  Ae  out- 
Ae-window  (OTW)  image  generation  windows. 

b)  The  indication  Ae  appropriate  models  for  potential  mclusion  into  Ae  sensor  and 
OTW  images  along  with  Ae  controls  for  each  model's  visibility  and  illumination  as 
appropriate  for  Ae  TOD,  visibility  range  and  environment^  conditions  as  fog, 
clouds,  smoke  and,  for  moving  ground  vehicles  as  requited  by  shadow  occultation 
of  models  determined  to  be  m  Ae  shadow  of  some  terrain  model  as  determmed  by 
Ae  Intervisibility  Function;  and  as  requited  by  Ae  image  generation  function  model 
prioritization  control  (which  may  require  the  services  of  the  Intervisibility 
Function). 

c)  The  positions  and  attitudes  of  all  potentially  visible  moving  models  along  wiA 
appropriate  articulated  part  data,  mcluding  ownship  rotor  control. 

d)  Activation  and  control  of  Ae  animation  of  sequences  representing  weapons  and 
oAer  effects. 

e)  Activation  and  position  control  of  Ae  Asplay  of  environmental  models. 

f)  The  level-of-detail  transitioning  into  view  of  models  mtroduced  mto  Ae  scene  at 
such  a  distance  Aat  Aeir  abrupt  appearance  would  create  Astracting  anomalies. 
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3. 1.4.2. 3. 9.  Visual  Data  Base  Control.  The  VSC  Function  shall  support  the  dynamic 
loading  of  the  image  generator  memories  with  terrain,  moving  and  envirotunental  models  as 
these  models  become  required  for  the  generated  images  (Refer  to  the  Scene  Models 
paragraph  of  the  Image  Generation  Function  speciflcation).  When  data  base  models  are 
required,  they  are  retrieved  from  the  visual  system  data  base  mass  storage  device.  The  time 
constraints  on  the  retrieval  and  loading  of  data  models  are  discussed,  when  appropriate, 
with  each  model  category. 

The  VSC  Function  also  supports  the  data  model  loading  required  during  the  Simulation 
Initialization  state  proscribed  by  the  mission  and  initial  parameters.  In  this  state,  all  models 
of  certain  types  may  be  loaded  in  order  to  enable  rapid  activation  during  the  Run  state. 

3.1.4.2.3.9.1.  Terrain  Data  Base  Retrieval.  The  VSC  Function  shall  support  the 
dynamic  retrieval  and  image  generator  loading  of  the  terrain  model  data  within  a  500  km  by 
5(X)  km  region.  This  function  shall  maintain  a  360  degree  region  around  the  ownship  to  a 
distance  sufficiently  beyond  the  commanded  visibility  ranges  of  the  OTW  and  sensor 
images  to  avoid  visible  popping  into  the  scene  of  terrain  models.  (The  maximum  visibility 
ranges  required  are  given  in  the  Scene  Models  paragraph  of  the  Image  Generator  Function). 
This  dynamic  retrieval  and  loading  must  be  sustainable  for  ownship  speeds  not  less  than 
300  nautical  miles  per  hour. 

The  VSC  Function  shall  support  the  retrieval  and  loading  of  different  LOD  of  terrain 
models  if  this  is  required  by  the  Image  Generation  Function. 

The  terrain  data  base  retrieval  process  shall  include  the  retrieval  and  loading  of  all  terrain 
cultural  features  including  library  and/or  procedural  models  and  specific  texture  patterns  ( if 
their  loading  is  not  part  of  simulation  initialization). 

3.1.4.2.3.9.2.  Moving  Model  Data  Control.  The  VSC  Function  shall  retrieve  and 
load  into  the  image  generator  memories  representations  of  those  moving  models  which  are 
potentially  visible  to  any  of  the  active  fields  of  view  (OTW  or  sensor  '^s).  A 
deterrrunation  shall  be  made  as  to  which  active  moving  models  are  potentially  visiole  (this 
may  require  the  Intervisibility  Function)  and,  if  data  are  required  to  be  retrieved  and  loaded 
for  display,  this  process  shall  be  accomplished  in  a  manner  which  avoids  popping  or  other 
noticeable  anomalies  in  the  scene. 

There  shall  be  no  noticeable  time  delays  in  the  activation  of  weapon  effects  due  to  retrieval 
and  loading  processes. 

3.1.4.2.3.9.3.  Environmental  Model  Data  Control.  Except  for  time  critical  models 
(e.g.,  lightning),  the  environmental  models  may  be  retrieved  and  loaded  based  upon 
activation  control  received  via  the  ARWA  Global  bus. 

3.1.4.2.3.10.  Intervisibilitv  Control.  The  VSC  Function  shall  provide  interface  capability 
betwren  the  Intervisibility  Function  of  the  Visual  System  Module  and  both  VSC  intemtd 
functions  and  functions  exterior  to  the  entire  Visual  Module.  In  both  cases  the  VSC  shall 
receive  requests  for  the  use  of  the  Intervisibility  Function.  TTiese  requests  will  be 
reformatted  as  required  and  transferred  to  the  Intervisibility  Function  within  5  milliseconds. 
Results  of  these  requests,  when  made  available  by  the  Intervisibility  Function,  shall  be 
returned  to  the  ARWA  Global  bus  or  the  appropriate  internal  function  within  15 
milliseconds. 

The  capability  of  the  VSC  Function  to  process  these  requests  and  results  shall  not  restrict 
the  throughput  of  the  Intervisibility  Function. 
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3.1.4.2.3.11.  Visual  System  Load  Control.  The  VSC  Function  shall  monitor  visual 
system  load  indicators,  anticipate  potential  overload  conditions  and  take  corrective  actimi  to 
avoid  overload  conditions  which  could  distract  from  mission  performance.  Any  corrective 
action  shall  be  performed  in  a  gradual  manner  to  avoid  rapid  changes  in  the  visual  image 
and  in  other  areas  of  system  performance.  Acceptable  corrective  actions  include: 

a)  The  selective  adjustment  by  scene  feature  type  of  the  distance  at  which  models 
switch  between  level-of-detail  (LOD)  representations. 

b)  The  adjustment  to  the  distances  beyond  which  models  are  excluded  from  the 
generated  image. 

c)  The  adjustment  to  the  minimum  subtended  solid  angle  for  the  display  of 
polygonal  faces. 

d)  Other  non-distracting  adjustments  which  do  not  affect  system  transport  delays 
and  Held  times. 

There  shall  be  parametric  control  over  which  mix  of  corrective  actions  are  employed  in  a 
given  mission  scenario. 

3.1.4.2.3.12  Spare  Requirements.  There  shall  be  50%  spare  capacity  for  VSC 
processing  and  in  the  VSC  main  memories. 

3. 1.4.3.  Image  Generation  Function. 

3. 1.4.3. 1.  Purpose.  This  function  generates  the  video  image  for  the  OTW  scene  for 
both  crew  members  and  the  video  for  the  two  sensor  images  which  are  destined  for  the 
helmet  display  and/or  the  multi-functional  displays  (MFDs)  in  the  cockpit.  The  images 
generated  by  this  function  are  determined  by  the  control  data  and  scene  model  data  provided 
by  the  Visual  System  Control  Function. 

3.1. 4.3.2.  Physical  Characteristics.  The  requirements  for  this  function  shall  be  met  by 
one  or  several  image  generation  systems  driven  by  the  image  generator  controller. 

3.1.4.3.3.  Performance  Characteristics. 

3. 1 .4.3.3. 1 .  Out-the-Window  Image.  The  equivalent  of  a  135  degrees  horizontal  by  70 
degrees  vertical  FOV  image  shall  be  presented  from  the  perspective  of  one  nominal 
eyepoint  in  the  cockpit  This  OTW  scene  shall  be  updated  at  30  Hz  and  have  a  refresh  rate 
of  60  Hz.  The  resolution  required  of  this  135  X  70  visual  image  shall  be  equivalent  to  that 
of  six  (6)  visual  channels,  each  producing  one-sixth  of  the  FOV,  with  640  X  480 
(pixels/^anlines).  The  image  generation  function  shall  have  at  a  minimum  the  capacity  to 
display  in  this  135  X  70  FOV  the  equivalent  of  each  of  these  six  visual  channels  displaying 
1200  visible  polygons-colored,  flat-shaded,  textured  and  fully  antialiased  polygons  (fully 
antialiased  means  at  least  the  equivalent  of  eight  subpixels  with  uniform  weighting).  The 
OTW  image  shall  support  ownship  speeds  not  less  than  300  nautical  miles  per  hour  and 
ownship  slew  rates  not  less  than  120  degrees  per  second.  Within  this  envelope  the  images 
shall  be  free  of  noticeable  skipping,  data  voids,  popping  and  occulting  anomalies. 

3.1.4.3.3.2.  Sensor  Images.  The  image  generation  function  shall  be  able  to  produce, 
simultaneously  with  the  OTW  image,  either  one  or  two  sensor  video  images.  These  images 
shall  be  updated  at  60  Hz  and  have  a  refresh  rate  of  60  Hz..  For  each  aircraft  given  in 
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Tables  3.1. 4.3-1  and  3.1. 4.3-2,  this  function  shall  be  able  to  produce  any  combination  of 
different  sensor  mode  images  along  with  their  corresponding  FOVs  and  magnifications. 
Each  sensor  image  shall  have  a  minimum  resolution  equivalent  to  640  X  480 
(pixels/scanlines).  The  image  generation  function  shall  have  the  capacity  to  display  in  each 
sensor  image  a  minimum  of  1200  visible  polygons- flat- shaded,  textured  and  fully 
antialiased  polygons  (fully  antialiased  means  at  least  the  equivalent  of  eight  subpixels  with 
uniform  wei^ting).  For  each  sensor  mode,  the  corresponding  monochromatic  image  shall 
provide  relative  intensities  of  polygonal  faces  as  characteristic  for  the  sensor  with  the  given 
TOD. 


Table  3. 1.4.3- 1  AH-64D  Sensor  Image  Characteristics 


Sensor  Mooe 

Diagonal 

FOV  (3:4 

Aspect) 
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TO 
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FUR 

1.0 

FLIR 

10.0 

5.7 

Tor 

3.1 

TO 

PNVS 

e&bmqhhhi 

1.0 

Table  3.1. 4.3-2  RAH-66  Sensor  Image  Characteristics 


Sensor  Mode 

Spectral 

Range 

(Microns) 

Helmet 

Display 

FOV(VxH) 

degs 

Magnification 

S.O  -  12.0 

DTV 

35  X  60 

LL 

Intensifier 

The  image  generation  function  shall  support  ownship  speed  not  less  than  3(X)  nm  per  hour 
and  combined  ownship/sensor  slew  rates  of  120  degrees  per  second.  Within  this  envelop, 
sensor  images  shall  be  free  from  skipping,  popping,  data  voids  and  prioritization 
anomalies. 

The  image  generation  function  supports  rapid  switching  of  sensor  modes  and  FOVs.  It 
shall  be  possible  to  generate  a  complete  video  image  of  a  new  FOV  within  0.25  seconds 
(measured  from  start  of  receipt  of  the  first  control  data  word  to  the  start  of  field  display  of 
the  new  FOV  sensor  image).  Using  this  same  measure,  between  mode  changes  shall  be 
accomplished  within  0.5  seconds.  Mode  and  FOV  switches  in  one  sensor  channel  shall  not 
have  any  visible  effect  in  the  other  sensor  or  the  OTW  images. 
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3. 1. 4.3.3. 3.  Transport  Delay.  The  time  from  the  start  of  transfer  of  new  position  and 
attitude  data  to  the  end  of  display  of  the  video  image  incorporating  these  data  updates  shall 
not  exceed  SO  milliseconds  and  100  milliseconds  for  the  sensor  and  O'HV  images, 
respectively.  These  delays  assume  the  best  case  synchronization  between  the  image 
generator  and  the  host  computer  from  which  the  positions  and  attitude  are  generated. 

3. 1 .4.3. 3.4.  Time-of-dav.  There  shall  be  a  minimum  of  ten  (10)  selectable  daytime  and 
night  conditions  for  each  of  which  the  corresponding  OTW  and  sensor  images  will  reflect 
as  appropriate  the  proper  background  color,  shading,  illumination  and  thermd  properties  of 
the  displayed  materials.  Changes  to  the  TOD  during  a  mission  shall  be  supported  and  shall 
be  accomplished  without  interruption  to  the  mission. 

3. 1.4.3. 3. 5.  Atmospheric  Fading.  The  image  generation  function  shall  support  the 
simulation  of  atmospheric  attenuation  for  a  continuous  range  of  visibility  conditions  from 
zero- visibility  (50  meters)  in  fog  conditions  to  the  visibility  to  support  maximum  retrieval 
ranges.  It  shall  be  possible  to  disable  all  atmospheric  fading.  The  simulated  visibility 
range  shall  be  dynamically  selectable  to  reflect  changing  atmospheric  conditions  as  well  as 
to  avoid  the  popping  of  newly  activated  scene  models.  It  is  desirable  to  have  dynamic 
control  over  main  characteristics  of  the  fading  function  (e.g.,  the  distances  at  which  fading 
begins  and  at  which  it  attains  a  given  percentage  of  fading  toward  a  targe'  background- 
black  or  white). 

3. 1. 4.3.3. 6.  Color  and  Sensor  Tables.  There  shall  be  a  sufficient  number  of  different 
color  and  sensor  tables  to  support  the  simultaneous  generation  of  the  OTW  and  two  sensor 
images.  There  shall  also  be  a  sufficient  number  of  such  tables  and,  if  required,  the 
capability  to  dynamically  substitute  these  tables  in  order  to  support,  for  each  aircraft  type, 
all  potentially  displayable  sensor  types  and  all  TOD  conditions. 

3. 1.4.3. 3.7.  Texture.  It  shall  be  possible  to  display  synthetically-generated  and 
photographically-derived  texture  patterns  on  all  visible  terrain  and  moving  model  faces. 
Color,  intensity  and  transparency  modulation  shall  be  supported.  The  storage  of  at  least 
one  million  texels  and  the  addressing  of  at  least  128  texture  patterns  shall  be  possible.  It 
shall  be  possible  to  have  texture  patterns  at  least  as  large  as  256  x  256  texels.  It  is  desirable 
that  multi-colored  texture  patterns  be  supported  as  well  as  the  blending  of  texture  patterns 
of  largely  different  scale  in  order  to  provide  continuous  texturing  over  a  large  dynamic 
range. 

3.1.4.3.3.8.  Translucencv.  There  shall  be  the  capability  to  display  translucent  faces  and 
there  shall  be  at  least  64  levels  for  translucency  ranging  from  completely  opaque  to 
completely  transparent.  This  translucency  capability  shall  be  applicable  to  LOD  model 
transitioning,  texturing  and  in  such  effects  as  clouds  and  smoke.  There  shall  be  sufficient 
frame  buffer  overwrite  capacity  to  support  a  translucency  overwrite  of  80  percent  of  the 
image  ( the  approximate  equivtdent  of  2.0  overwrites  per  pixel  for  non  z-buffered  systems 
and  4.0  for  z-buffered  systems).  When  these  capacities  are  exceeded,  the  image  generator 
shall  manage  this  overload  situation  in  a  non-obtrusive  manner).  Anti^asing  shall  apply  to 
texture  processing  with  a  quality  equivalent  to  8  subpixels  with  uniform  weighting. 

3. 1 .4.3. 3.9.  System  Load  Control.  The  Image  Generation  Function  shall  provide  the 
load  indicators  and  control  mechanisms  necessary  to  support  the  Visual  System  Load 
Control  requirements  specified  for  the  VSC  Function. 

3.1.4.3.3.10.  Scene  Models.  Below  are  given  the  various  types  of  models  which  the 
image  generation  function  shall  display.  There  models  shall  be  displayed  to  the 
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commanded  visibility  range  for  each  OTW  and  sensor  image.  The  maximum  visibility 
ranges  shall  not  less  Aan  tte  following: 

a)  10  kilometers  for  OTW,  and 

b)  IS  kilometers  for  each  sensor. 

In  order  to  provide  more  complex  scenes  within  the  capacity  of  the  image  generator,  multi- 
level-of-detail  representations  of  models  shall  be  supported  along  wiUi  LOD  transitioning 
using  translucency  fading. 

3.1.4.3.3.10.1.  Terrain  Model.  The  image  generation  function  shall  support  the 
dynamic  retrieval  of  the  terrain  data  base  and  shi^  provide  sufHcient  capacity  to  store  for 
immediate  image  generation,  along  with  the  active  moving  and  environmental  models,  a 
360  degree  region  around  the  ownship  which  extends  to  a  distance  sufficiently  beyond  the 
maximum  required  visibility  ranges  to  allow  terrain  data  loading  and  deletion  without 
noticeable  visible  effect,  given  the  maximum  allowable  ownship  sp^. 

To  maximize  scene  complexity  while  maintaining  the  image  generation  processing  load  and 
active  data  base  memory  size  requirements,  the  image  generation  function  shall  support  the 
use  of  library  models  and  procedural  models  such  as  two-dimensional  trees. 

3. 1 .4.3.3. 10.2.  Moving  Models.  The  image  generation  function  shall  support  the 
following  types  and  numbers  of  moving  models  which  shall  be  displayed  with  the  proper 
occulting  relationships  with  respect  to  the  other  moving  models  and  the  objects  in  the 
terrain  scene: 

a)  Ground  vehicles  with  six  degrees  of  freedom  of  motion  and  each  with  one 
articulated  part  with  at  least  one  degree  of  freedom  of  motion:  1000  active  within 
the  gaming  area  with  200  potentially  visible  in  each  generated  image  (i.e.,  within 
the  maximum  visibility  range  of  the  ownship). 

b)  Air  vehicles  and  air  weapons  (e.g.,  HellHre  missiles)  with  six  degrees  of 
freedom  of  motion  and  two  articulated  parts  each  with  one  degree  of  freedom  of 
motion  each:  16  simultaneously  visible  in  each  generated  image. 

c)  Weapon  effects,  including  Hre,  smoke,  bursts  and  explosions,  with  at  least  three 
degrees  of  freedom  of  motion:  40  simultaneously  visible  in  each  image  (OTW, 
each  sensor).  Each  of  these  weapon  effects  shall  be  represented  as  an  animated 
sequence  of  models;  the  maximum  allowable  number  of  models  per  sequence  shall 
be  no  less  than  256.  Flares  are  included  as  weapon  effects  and  shall  be  modeled  as 
self-illuminated  models. 

d)  Ownship  rockets  and  tracers,  with  three  degrees  of  freedom  and  each  with  a 
preassigned  occulting  priority:  35  simultaneously  visible  in  each  image. 

e)  Ownship  rotor  with  at  most  3  degrees  of  freedom  of  motion:  one. 

3. 1 .4.3.3. 10.3.  Environmental  MfldfilS-  The  following  environmental  effects  shall 
be  displayable:  Fog  and  cloud  layers,  above  and  below  the  ownship;  horizon  band; 
thunderclouds  and  lighming. 

3.1.4.3.3.10.4  Image  Generation  Summary.  Table  3.1. 4.3-2  provides  a  summary 
of  the  requirements  for  the  Image  Generation  Function.  There  are  some  addition  details 
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concerning  cost,  the  interface  with  the  VSC  and  data  bases  as  well  as  some  nontequired 
features. 

Table3.1.4.3-2  Summary  of  IG  Specifications 
[Continued  on  next  page] 
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Table  3. 1.4.3-2  Summ^  of  IG  Specifications 
[Continuaj] 


Notes  on  the  Image  Generator  Specification  Summary 

Channels  ;  Resolution  higher  than  640  x  480,  preferably  as  close  to  1280  x  1024  as 
possible,  is  one  of  the  most  desired  enhancements  over  the  minimum  specifications.  An 
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area-of-interest  display  system  may  be  proposed  to  achieve  equivalent  high  resolution. 
Approaches  providmg  higher  resolution  for  targets  are  also  acceptable.  The  cost  target  for 
image  generator  (IG)  plus  displays,  not  including  the  helmet  displays  and  cockpit  multi¬ 
function  displays  is  $  12S0K.  Sensors  channels  may  be  each  be  driven  from  a  single  color 
of  a  conventional  RGB  (red-green-blue)  channel.  The  two  sensor  eyepoints  may  be 
different  from  the  nominal  visual  eyepoints  and  may  change  as  different  sensors  are 
selected  for  display  on  each  of  the  two  channels. 

Antialiasing  :  If  the  antialiasing  and  subpixel  occlusion  methods  provide  less  quality 
than  the  equivalent  of  eight  subpixels  under  certain  circumstances,  those  circiunstances  are 
to  be  described  by  the  IG  vendor.  Examples  of  potentially  troublesome  circumstances  are 
edges  viewed  through  a  partially  transparent  object,  vertices  having  a  large  number  of 
adjoining  polygons,  Unes  of  interpenetration,  and  small  polygon  entirely  within  a  pixel. 

Polygon  capacity  :  Polygon  capacities  slightly  lower  than  the  nominal  specified  may  be 
proposed,  and  may  be  acceptable  if  there  is  a  substantial  cost  saving  or  if  other  features  of 
high  value,  such  as  enhanced  texture  or  high  resolution,  are  included. 

Pixel  capacity:  We  presume  that  all  polygon-based  IG  system  must  generate  more  pixel 
values  than  are  ultimately  displayed.  Extra  pixels  are  needed  so  that  two  or  more  pixel 
values  may  contribute  to  an  antialiased  pixel  containing  an  edge  or  vertex,  and  extra  pixels 
are  need  to  provide  translucent  surfaces  for  model  switching  and  special  effects.  The 
requirement  for  100%  extra  pixel  capacity  may  be  waived  if  an  innovative  approach  is 
proposed  to  avoid  the  potential  limitations  of  pixel  capacity.  Z-buffered  system 
conventionally  also  generate  pixels  which  are  ultimately  occluded  before  display,  thereby 
requiring  much  higher  overwrite  capacity. 

Texture:  Texture  must  be  perspectively  correct  and  free  from  distracting  artifacts  of  an 
kind.  It  must  appear  to  be  “stuck”  to  the  textured  surface  as  the  viewpoint  changes  with 
respect  to  the  surface. 

Moving  Models:  Aircraft  models  must  be  correctly  occluded  at  all  times.  Ownship 
weapons  effects  may  use  approximate  occlusion  techniques  if  a  rationale  of  acceptability  is 
given.  The  entire  simulation  scenario  may  include  up  to  2000  tanks  or  other  ground 
vehicles,  up  to  200  of  which  may  be  in  view  at  any  one  time.  Occlusion  of  ground 
vehicles  may  be  in  error  for  up  to  1/15  second  when  the  occlusion  geometry  changes; 
although  it  is  preferable  that  no  errors  occur. 

Dynamic  Retrieval:  At  least  1  GByte  of  writable  disc  storage  must  be  included  with  the 
IG,  and  a  means  for  downloading  data  bases  off-line,  through  the  visual  system  controller 
interface,  must  be  provided.  The  disc  storage  must  have  sufticient  capacity  to  contain  the 
entire  data  base  requited  for  any  given  mission. 

Controller  Interface:  If  five  9U  VME  slots  ate  provided  in  a  VME  backplane  within  the 
IG  for  the  purpose  of  housing  the  Visual  System  Controller,  than  the  IG  interface  may  be 
accomplished  directly  over  the  VME  backplane  instead  of  by  external  DMA.  If  the 
Controller  is  separately  housed,  a  receiving  9U  VME  card  must  be  provided  capable  of 
driving  up  to  12  feet  of  interconnecting  cable. 

Modeling  System:  The  intent  is  to  use  Multigen  for  database  editing  and  to  use  the 
Multigen  Right  format  for  commonality,  as  many  existing  data  bases  may  easily  be 
translated  into  the  flight  format.  Note  that  a  modeling  system  is  not  bundled  with  the 
procurement  of  the  image  generator. 
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Cost:  The  cost  target  for  the  IG  plus  OTW  displays  and  helmet  displays  is  $1370  K. 
Tradeoffs  may  be  made  among  these  elements  to  provide  a  system  solution,  if  desired. 
Alternatives  providing  cost  and  performance  trades  roughly  over  the  range  of  +50%  and 
-30%  of  the  nominal  cost  are  encouraged. 

Demonstration  data  base:  The  purpose  of  the  demonstration  data  base  is  solely  to 
facilitate  system  integration  and  acceptance  of  the  image  generator.  It  must  be  Multigen 
compatible,  include  data  for  at  least  one  animated  sequence,  include  at  least  one  moving 
model  type,  and  at  least  one  model  switching  sequence  to  show  the  level-of-detaU 
c^ability. 

3. 1.4.4.  Display  Device  Function. 

3. 1.4.4. 1.  Purpose.  The  role  of  the  Display  Device  Function  is  to  display  to  the  two 
crew  members  the  OTW  video  image  generated  by  the  Image  Generation  Function  and  to 
display  the  sensor  images  which  are  intended  for  helmet  display.  The  video  for  the  OTW 
scene  (six  channels  of  video  are  proposed)  is  produced  by  die  teage  Generation  Function 
and  routed  direcdy  to  the  OTW  display  device.  The  video  for  the  two  sensor  images  is  first 
routed  from  the  Image  Generation  Fimction  to  the  Right  Station  Module  which  adds  the 
necessary  symbology  and  either  returns  the  merged  video  to  the  Display  Device  Function 
for  display  in  one  or  both  crew  member  helmets  and/or  is  retained  by  the  Flight  Station 
Module  for  display  in  one  or  several  multifunction  displays  in  the  cockpit 

3.1. 4.4.2.  Physical  Characteristics.  The  Display  Device  Function  shall  have  two  types 
of  display  systems  for  each  ARWA  device:  The  OTW  display  system  and  the  helmet- 
mounted  display  system.  All  cockpit  arrangements  (  the  tandem  AH-64D  and  RAH-66 
cockpits)  shall  use  the  same  OTW  display  device  and  helmet  displays. 

There  shall  be  two  helmet  display  systems  for  an  ARWA  device.  Each  helmet  display  shall 
be  able  to  provide  the  simulation  of  the  AH-64D  monocle  of  Integrated  Helmet  and  Display 
Sight  System  (IHADSS)  and  the  RAH-66  binocular  display  of  the  Helmet  Integrated 
Display  Sight  System  (HIDSS). 

The  OTW  display  system  shall  support  the  different  cockpit  configurations  such  that  any 
reconfiguration  required  of  the  OTW  display  system  to  accommodate  a  cockpit  change  shall 
be  accomplished  within  the  required  reconnguration  time  (Refer  to  Volume  I,  Paragraph 
3.1.4). 

The  size  of  the  OTW  display  system  shall  be  such  that  a  single  ARWA  device  is  able  to 
have  a  fooq)rint  not  exce^ing  the  16  foot  by  16  foot  area  requirement 

3.1. 4.4.3.  Performance  Characteristics.  Below  are  given  the  main  performance 
characteristics  which  must  be  provided  by  the  Visual  Mod^e  Display  Device  Function. 
When  appropriate,  the  OTW  and  helmet  sensor  display  characteristics  are  discussed 
separately  in  each  of  the  following  paragraphs. 

3. 1. 4.4.3. 1.  Field  Of  View.  In  each  of  the  different  types  of  cockpit  configurations,  the 
OTW  display  device  shall  support  the  FOV  requirements  of  the  Image  Generation  Function 
from  an  eyepoint  position  midway  between  the  nominal  head  position  of  the  two  crew 
members.  The  displayed  Held  of  view  may  be  static  in  relationship  to  the  ownship 
orientation. 

The  helmet  display  shall  be  able  to  support  a  30  degree  by  40  degree  FOV  in  the  monocular 
mode  and  a  40  degree  by  60  degree  FOV  in  the  binocular  mode. 
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3. 1 .4.4.3.2.  R^olution.  The  resolution  of  the  OTW  display  device  shall  be  such  that  the 
combined  resolution  capability  of  the  display  device  coupled  with  the  image  generator  are 
not  less  than  the  resolution  provided  by  Image  Generation  Function  for  the  OTW  image  or 
eight  (8)  arc  minutes  per  optical  line  pair,  whichever  requirement  is  the  less  restrictive. 

Similarly,  for  the  helmet  display,  the  combined  resolution  capability  shall  not  be  less  than 
the  minimum  resolution  provided  by  Image  Generation  Function  for  the  sensor  images  or 
eight  (8)  arc  minutes  per  optical  line  pair,  whichever  requirement  is  the  less  restrictive. 

3. 1.4.4.3.3.  Luminance.  The  OTW  display  device  shall  provide  a  minimum  of  6  foot- 
lamberts  as  measured  from  the  nominal  eyepoint  the  center  of  each  channel.  The 
luminance  mismatch  between  channels  shall  less  than  5%. 

The  analogous  luminance  requirements  shall  apply  to  the  monocular  and  binocular  helmet 
displays. 

3. 1 .4.4.3. 4.  Contrast  Ratio.  Both  the  OTW  and  the  helmet  displays  shall  provide  at  least 
a  15:1  contrast  ratio  (measured  using  a  checkerboard  pattern). 

3.1. 4.4.3. 5.  Color  Convergence.  The  OTW  display  devices  shall  have  color 
convergence  errors  of  less  than  0.2%  of  channel  picture  height.  Apparent  discrepancies 
between  the  color  display  of  different  channels  shall  be  correctable  without  the  replacement 
of  system  hardware. 

3. 1 .4.4.3. 6.  Geometric  Distortion.  For  each  channel  of  the  OTW  display  the  maximum 
geometric  distortion,  from  the  perspective  of  the  nominal  eyepoint,  shall  be  less  than  2%  of 
die  channel  picture  height.  Geometric  edge  matching  errors  between  adjacent  channels 
shall  be  less  than  0.5%  of  picture  height. 

For  the  helmet  display  device,  the  maximum  geometric  distortion  shall  be  2%  of  picture 
height.  There  shall  be  no  observable  artifacts  due  to  the  overlapping  of  the  two  binocular 
views. 

There  will  be  some  geometric  distortion  due,  not  to  the  display  device  itself,  but  to  the 
displacement  of  the  crew  members'  viewpoints  from  the  single  eyepoint  from  which  the 
OTW  images  are  generated. 

This  discrepancy  between  different  viewing  positions  of  the  two  crew  members  and  the 
image  eyepoint  also  results  in  different  look-angles  to  the  same  display  object  for  the  two 
crew  members.  While  the  above  two  types  of  geometric  distortion  are  not  considered 
detrimental  to  the  ARWA  mission  goals,  proposals  for  visual  system  should  address 
methods  by  which  they  can  be  minimized. 

3. 1.4.5.  Intervisibilitv  Function. 

3. 1 .4.5. 1 .  Purpose.  The  Intervisibility  Function  provides,  for  both  the  Visual  Module 
and  the  other  modules  of  the  ARWA  device,  various  computational  services  to  determine 
the  relationships  between  selected  models  and  positions  in  the  data  base  (occulting 
relationships,  distances,  penetrations)  or  between  positions  of  a  model  or  eyepoint  at  two 
different  times  (extrapolation)  or  between  one  position  and  orientation  in  different 
coordinate  systems  (coordinate  transformations). 
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3. 1 .4.5.2.  Physical  Characteristics.  There  are  several  possible  physical  realizations  of 
the  system  providing  the  computational  environment  for  the  IntewisibiUty  Function. 

The  proposed  realization  (Refer  to  the  ADST  Step  One  Technical  Report,  Section  4.0)  is  a 
stand-alone  computation  system  which  includes  a  data  base  representation  of  the  terrain  and 
moving  models.  This  computational  system  is  linked  to  the  Visual  System  Controller  via 
and  EDDI  bus  and  can  therefore  be  potentially  shared  by  the  other  ARWA  devices  and  all 
future  semi-automated  forces  (SAFOR)  devices. 

Other  realizations  include  the  Tntervisibility  Function  being  shared  between  the  visual 
system  controller  and  the  image  generator  or  being  shared  between  the  visual  system 
controller,  the  image  generator  and  a  separate  computational  system  which  performs  only  a 
portion  of  the  Intervisibility  Function. 

3. 1 .4.5.3.  Performance  Characteristics.  The  Intervisibility  Function  shall  provide  the 
types  of  computations  described  in  the  paragraphs  below.  With  each  computational  type, 
there  is  an  indication  of  the  data  required  for  the  computation,  the  product  of  the 
computation  and  a  specification  of  how  many  such  computations  (tests)  are  required  per 
second.  For  all  test  types  discussed  below,  it  shall  be  possible  to  exclude  data  models  by 
data  base  type  (e.g.,  exclude  all  tree  models). 

3. 1.4.5. 3.1.  Occulting  Determination.  For  this  test  type,  two  positions  in  data  base 
coordinates  are  given  and  the  test  computation  determines  whether  the  line  segment  (or 
volume  centered  around  the  line  segment)  intersects  some  data  base  model.  Occulting 
determination  tests  are  used: 

a)  To  decide  which  threats  are  visible  to  the  ownship  for  possible  display  and/or 
possible  inclusion  on  a  tactical  map. 

b)  To  determine  whether  the  ownship  is  occulted  from  radars,  electronic  warfare 
(EW)  sensors  and  communication  devices. 

c)  (For  SAFOR  use)  To  determine  for  each  threat  when  it  can  detect  and/or  engage 
the  ownship. 

d)  To  support  the  assignment  of  occulting  relationships  among  all  moving  models 
in  the  event  that  a  non  z-buffered  image  generator  requires  support  from  the  VSC 
Function. 

The  Intervisibility  Function  shall  support  (for  each  ARWA  device)  a  minimum  of  500 
occulting  determination  tests  per  second  of  an  average  length  of  one-half  the  maximum 
visibility  range.  With  the  introduction  of  SAFOR,  the  Intervisibility  Function  shall  support 
an  additional  5(X)0  occulting  test  per  second  of  an  average  length  of  one-half  the  maximum 
visibility  range. 

3.1.4.5.3.2.  Distance  Determination.  This  type  of  intervisibility  test  requires  a  starting 
position  and  either  an  ending  position  or  direction.  The  test  returns  a  distance  to  the  closest 
data  base  model  from  the  starting  position  along  the  ray  toward  the  ending  position  or  in  the 
given  direction.  Aso  returned  with  the  distance  is  a  model  type  descriptor.  This  distance 
determination  test  can  be  used: 

a)  To  simulate  the  ownship  laser  range  finding  capability. 
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b)  To  determine  height  above  terrain  of  above  other  objects  in  (vder  to  simulate  the 
radar  altimeter  function  and  to  simulate  landings  (height  above  ground  of  the 
landing  gears). 

c)  To  determine  ownship  weapon  impact  points  for  weapon  scoring. 

The  Intervisibility  Function  shall  support  (for  each  ARWA  device)  a  minimum  of  120 
distance  determinations  per  second  of  an  average  length  of  one-half  the  maximum  visibility 
range. 

3. 1.4.5. 3. 3.  Volume  Penetration  Determination.  This  Intervisibility  Function  test  is 
given  a  position  and  orientation  of  a  volume  (e.g.,  as  enclosed  by  six  planes)  and  the  test 
returns  an  indication  of  whether  there  is  a  penetration  of  this  volume  by  any  data  base 
models.  The  volume  penetration  test  can  be  used: 

a)  To  determine  ownship  hard  and  soft  (tree  branches)  crashes. 

b)  To  decide  when  a  moving  threat  has  penetrated  a  nondisplayable  shadow 
volume  of  another  model  and  thus  should  be  given  reduced  visibility  from  the 
ownship. 

c)  To  allow  SAFOR  moving  models  to  avoid  data  base  models. 

The  Intervisibility  Function  shall  support  (for  each  ARWA  device)  a  minimum  of  30 
volume  penetration  tests  per  second.  SAFOR  will  require  500  volume  penetration  test  per 
second. 

3. 1 .4.5.3.4.  (Ground  Vehicle  Placement.  This  is  the  capability  to  determine  the  correct 
position  and  attitude  of  a  ground  vehicle  for  placement  on  a  terrain  face  based  on  the 
projected  position  on  the  XY  plane.  This  determination  would  involve  the  use  of  a  height- 
above-terrain  type  test  for  the  first  appearance  of  a  vehicle  on  a  terrain  face.  Additional 
position  and  attitudes  for  the  same  face  are  directly  derivable  from  those  of  the  first 
appearance. 

This  type  of  ground  placement  is  required  to  keep  on  (not  above  or  below)  the  surface  of 
the  terrain  vehicles  which  have  been  positioned  by  non- ARWA  systems.  These  systems 
may  use  geometrically  different  models  of  the  terrain  and  will  provide  outdated  position 
data  due  to  transport  delays.  Any  system  (e.g.,SAFOR)  which  controls  the  movement  of 
ground  vehicles  will  require  this  capability. 

Each  ARWA  device  requires  a  minimum  of  1000  vehicle  placement  test  per  second. 

3.1.4.5.3.5.  Extrapolation  and  Coordinate  Conversion.  If  the  Intervisibility  Function  is 
a  resource  shared  between  several  ARWA  devices,  redundant  conversions  of  position  and 
attitude  data  to  the  coordinate  systems  used  in  the  ARWA  devices  can  be  eliminated.  If,  in 
addition,  the  ARWA  devices  are  synchronized,  redundant  extrapolation  computations  can 
also  be  eliminated. 

3. 1.4.6.  Helmet  Tracker  Function. 

3. 1 .4.6. 1 .  Purpose.  The  Helmet  Tracker  Function  provides  to  the  VSC  Function  the 
position  and  attitude,  relative  to  the  cockpit,  of  helmet  of  each  crew  member.  These  data 
are  used  by  the  VSC  Function  to  compute  the  field  of  view  for  the  generation  of  the  sensor 
images. 
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3. 1 .4.6.2.  Physical  Characteristics.  The  device  or  devices  (there  will  most  likely  be 
two)  shall  not  obstruct  the  crew  members  view  of  the  cockpit  or  the  OTW  display  and  shall 
be  capable  of  a  physical  interface  with  the  VSC  in  a  manner  which  adds  less  than  one 
millis^ond  delay. 

3. 1 .4.6.3.  Performance  Characteristics.  The  Helmet  Tracker  Function  shall  provide 
the  VSC  Function  with  helmet  positions  and  attitudes  for  the  two  crew  members  at  a  rate  of 
60  Hz.  There  shall  be  less  than  an  eight  (8)  millisecond  delay  from  the  time  the  positional 
data  was  obtained  to  the  time  they  are  available  to  the  VSC.  The  accuracy  of  the  positional 
data  generated  by  the  Head  Tracker  Function  shall  be  such  that  there  is  no  noticeable 
irregularities  in  the  resulting  sensor  image.  The  function  shall  be  able  to  provide  accurate 
positional  information  for  all  helmet  position  and  attitudes  encountered  during  mission 
simulation.  The  Helmet  Tracking  Function  shall  support  all  aspects  of  Visu^  Module 
diagnostics  as  described  in  Paragraphs  3.1.3  and  for  the  VSC  Function.. 

3. 1.4.7.  Data  Base  Storage  Function. 

3.1. 4.7.1.  Purpo.se.  The  purpose  of  this  function  is  to  store  for  retrieval  during 
Simulation  Mode  the  terrain  and  other  data  base  mods  in  support  of  the  current  mission. 

3. 1 .4.7.2.  Phv.sical  Characteri.stics.  The  physical  medium  for  data  base  storage  shall 
be  removable  to  obviate  the  need  to  clean  the  medium  of  secure  data  during  Shut  Down 
Mode. 

The  Data  Base  Storage  Function  shall  be  able  to  provide  storage  of  the  entire  data  base 
required  for  a  mission.  This  shall  include  the  5()0  km  by  500  km  gaming  area  and  all 
moving  and  environmental  models.  It  shall  be  possible  to  update  the  stored  data  base  with 
data  base  revisions  and/or  new  data  base  to  support  new  missions. 

The  Data  Base  Storage  Function  shall  allow  retrieval  rates  specified  for  the  VSC  Function. 

This  function  shall  support  the  equipment  test  and  morning  readiness  diagnostics  described 
in  Paragraph  3.1.3. 

3. 1.4.7. 3.  Performance  Characteristics.  Refer  to  Data  Base  Storage  Function, 
Physical  Characteristics. 

3.1.5.  Module  Functional  Relationships.  Figure  3.1.4-1  provides  a  top-level  view  of  the 
interrelationship  of  the  various  functions  of  the  Visual  module.  The  control  and  data 
exchange  among  these  functions  is  described  in  the  relevant  sections  of  Paragraph  3.1.4. 

3.1.6.  Configuration  Allocation.  In  addition  to  the  requirements  contained  in  Volume  I  of 
this  specification.  Paragraph  3.1.6,  the  Visual  Module  has  additional  requirements  which 
are  given  in  this  paragraph.  The  Visual  Module  shall  be  comprised  of  one  Computer 
Software  Configuration  Item  (CSCI)  and  seven  (7)  Hardware  Configuration  Perns 
(HWCI).  The  allocation  of  these  configuration  items  is  as  follows: 

a)  CSCI  #1:  Visual  System  Controller  Function  Software 

b)  HWCI#1:  ARWA  Global  Bus  Interface  Function  Hardware 

c)  HWCI  #2:  Visual  System  Controller  Function  Hardware 
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d)  HWCI#3:  Image  Generation  Function  Hardware 

e)  HWCI#4:  E>isplay  Device  Function  Ihtrdware 

f)  HWCI#S:  Intervisibility  Function  Hardware 

g)  HWCI#6:  Helmet  Tracker  Function  Hardware 

h)  HWCI#7:  Data  Base  Storage  Function  Hardware 

3.1.7.  Interface  Requirements.  The  various  internal  and  external  interfaces  are  illustrated 
in  Figure  3.1.4-1. 

3. 1 .7. 1 .  External  Interfaces.  The  external  interfaces  for  the  Visual  Module  shall 
consist  of  the  following: 

a)  ARWA  Global  Bus  Interface.  This  is  the  interface  of  the  Visual  Module  with  the 
other  modules  in  the  ARWA  device.  The  ARWA  Global  bus  interface  requirements 
are  given  in  Volume  I  of  this  specitication.  Paragraph  3.1.7  and  the  ARWA  SSM 
IDD,  Appendix  A. 

This  interface  also  provides  the  interface  of  the  Visual  Module  with  the  Simulation 
Manager  including  the  program  Hies  of  the  Software  Maintenance  Station  and  the 
data  base  files  of  tiie  Data  Base  Maintenance  Station.  In  addition,  when  the  Visual 
Module  is  in  the  stand-alone  state  of  Module  Mode,  any  workstation  connected  to 
the  network  can  act  as  a  control  console  for  the  stand-alone  operations.  The 
commands  and  data  required  in  stand-alone  state  are  given  in  the  paragraph 
concerning  the  stand-alone  operations  of  the  VSC  Function,  Section  3.1.4. 

This  interface  shall  also  logically  support  the  communications  between  the 
Intervisibility  Function  and  the  intervisibility  control  of  the  VSC  Function.  A 
description  of  the  contents  of  the  communications  between  these  two  functions  is 
given  in  the  paragraph  concenung  the  Intervisibility  Function  in  3.1.4  of  this 
salification.  In  addition,  during  the  alignment  state  of  Simulation  Mode,  the 
Visual  Module  can  transfer  data  base  files  from  the  Data  Base  Mai’^tenance  Station 
and  the  data  base  storage  of  the  Visual  Module. 

b)  Flight  Station  Interface.  The  Visual  Module  produces  up  to  ;wo  channels  of 
video  imagery  which  is  routed  to  the  Flight  Station  Module.  Symbology  is  then 
merged  with  these  video  outputs  and  they  are  then  routed  by  the  Flight  Station 
Module  for  display  in  the  MFDs  of  the  cockpit  and/or  in  one  or  both  helmet 
displays. 

3. 1.7. 2.  Internal  Interfaces.  Figure  3.1.4-1  provides  a  top-level  view  of  the 
interfaces  of  the  various  components  of  the  Visual  module.  The  physical  nature  of  these 
interfaces  and  the  logical  contents  of  the  communication  between  these  component  are 
described  in  the  relevant  paragraphs  of  Paragraph  3.1.4  of  this  specification. 

3.1.8.  Government  Furnished  Property.  The  following  is  the  government  furnished 
property  required  by  the  Visual  Module  in  addition  that  speciBed  in  Paragraph  3.1.8  of 
Volume  I  of  this  specification: 

3.2.  System  Characteristics.  The  system  characteristic  requirements  for  the  Visual 
Module  shall  be  as  specified  in  Paragraph  3.2  of  Volume  I  of  this  specification. 
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3.3.  Visual  Module  Processing  Resources.  The  System  Processing  Resources 
requirements  of  Paragraph  3.3  of  Volume  I  of  this  specification  shall  all  to  the  processing 
resources  of  the  Visud  Module. 

3.4.  Quality  Factors.  The  requirements  of  Paragraph  3.4  of  Volume  I  of  this 
specification  shall  apply. 

3.4.1.  Reliability.  The  requirements  of  Paragraph  3.4  1  of  Volume  I  of  this  specification 
shall  apply. 

3.4.2.  Maintainability.  The  requirements  of  Paragraph  3.4  2  of  Volume  I  of  this 
specification  shall  apply. 

3.4.3.  Flexibility  and  Expansion.  The  requirements  of  Paragraph  3.4  3  of  Volume  I  of 
this  specification  shall  apply. 

3.4.4.  Ayailability.  The  requirements  of  Paragraph  3.4  4  of  Volume  I  of  this  specification 
shall  apply. 

3.4.5.  Portability.  The  requirements  of  Paragraph  3.4  5  of  Volume  I  of  this  specification 
shall  apply. 

3.5.  Logistics.  The  logistics  requirements  specified  in  Paragraph  3.5  of  Volume  I  of 
this  specification  shall  apply  to  the  Visual  Module. 

3.6.  Precedence.  The  precedence  requirements  specified  in  Paragraph  3.6  of  Volume  I 
of  this  specification  shall  apply  to  the  Visual  Module. 

4.  VERMCATION  REQUIREMENTS 

4. 1  General.  The  system  leyel  general  yerification  eyents,  leyels  and  methods  of  testing 
for  the  Visual  System  module  are  defined  in  Volume  I  of  this  specification,  paragraph  4.1 
and  all  subparagraphs  of  paragraph  4.1.  For  the  Visual  System  module  operating  in  the 
ARWA  SS,  there  are  no  additional  general  yerification  requirements. 

4.1.1  Philosophy  of.  Testing.  In  addition  to  the  testing  philosophy  identified  in  Volume  I 
of  this  specification,  paragraph  4.1.1,  informal  standalone  module  testing  shall  be 
conducted  for  the  flight  station  module  prior  to  integration  with  the  system.  The  intent  of 
these  tests  shall  be  to  identify  and  resoWe  any  unique  module  related  deficiencies  prior  to 
system  integration  thus  reducing  integration  problems. 

4. 1.1.1  Testing  Eyents.  Scheduled  testing  shall  take  place  sequentially  in  the 
following  phases. 

4. 1 . 1 . 1 . 1  Verification  Verification  test  at  a  system  leyel  shall  be  conducted  as 
specified  in  Volume  I  of  this  sproification,  paragraph  4. 1.1. 1.1.  Module  leyel  yerification 
testing  shall  be  accomplished  prior  to  shipment  of  the  module  to  the  integration  facility  and 
shall  ensure  that  the  module  meets  the  functional  and  performance  requirements  of  this 
yolume  of  the  specification. 

4. 1 . 1 . 1 .2  Acceptance  Test.  Acceptance  test  at  a  system  leyel  shall  be  conducted  as 
specified  in  Volume  I  of  this  specification,  paragraph  4.1.1. 1.2.  Module  leyel  acceptance 
testing  shall  consist  of  installation  and  checkout  of  tte  module  at  the  integration  facility  and 
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accomplishment  of  a  subset  of  the  module  level  verification  tests  to  ensure  that  the  module 
meets  the  functional  and  performance  requirements  of  this  volume  of  the  specification  in  the 
installed  configuration. 

4.1.2  Location  of  Testing.  All  system  level  testing  shall  be  accomplished  in  the  locations 
identified  in  Volume  I  of  this  specification,  paragraph  4.1.2.  All  module  level  verification 
testing  shall  be  accomplished  at  the  module  builders  facility.  All  module  level  acceptance 
testing  shall  be  accomplished  at  the  system  integration  facility. 

4.1.3  Re.spon.sihilitv  for  Te.st.s.  The  responsibility  for  system  level  testing  shall  be  as 
defined  in  Volume  I  of  this  specification,  paragraph  4.1.3.  The  responsibility  for  module 
level  testing  shall  be  allocated  to  the  module  builder  and  system  integrator. 

4. 1 .4  Verification  Methods.  Verification  methods  shall  be  as  defined  in  Volume  I  of  this 
specification,  paragraph  4.1.4. 

4.2  Formal  Tests.  Formal  test  shall  consist  of  functional  and  performance  testing. 

4.2.1  Performance  Evaluation.  Performance  evaluations  which  verify  the  design  and 
development  of  the  configuration  items  shall  be  performed  to  test  that  the  design  and 
performance  of  the  configuration  items  meet  the  requirements  specified  in  paragr^h  3.1  of 
this  Volume  and  Volume  I  of  this  specification.  Performance  evaluation  shall  consist  of 
inspections,  analyses,  demonstrations  and  tests. 

4.2.3  Reliability  and  Maintainability.  Reliability  and  maintainability  testing  shall  not  be 
performed. 

4.2.4  Test  Equipment.  Test  equipment  requirements  applicable  to  all  modules  are 
described  in  Volume  1  of  this  specification,  paragraph  4.2.4.  'niere  is  no  additional  module 
unique  test  equipment  required  to  verify  that  the  co^guration  items  and  assembled  module 
meet  the  requirements  specified  in  paragraph  3,  Requirements,  of  this  Volume  and  Volume 
I  of  this  specification. 

4.3  Formal  Test  Constraints.  The  formal  test  constraints  for  the  ARWA  SS  system  are 
described  in  Volume  I  of  this  specification,  paragraph  4.3.  There  are  no  additional  formal 
test  constraints  unique  to  the  Visual  System  module. 

4.4  Verification  Cross  Reference.  Table  1,  Visual  System  Verification  Cross  Reference 
Matrix,  provides  a  requirements/verification  cross  refe.ence  guide  for  the  Visual  System 
module  using  the  definitions  provided  in  Volume  I  of  this  specification,  paragraph  4.1.4. 
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Table  4.  Visual  System  Module  Verification  Cross  Referrace  Matrix 
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Table  4.  Visual  System  Module  Verification  Cross  Reference  Matrix 
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Table  4.  Visual  System  Module  Verification  Cross  Reference  Matrix 

[Continued] 


5 .  PREPARATION  FOR  DELIVERY 

The  preparation  for  delivery  requirements  for  the  ARWA  SS  are  speciEed  in  Volume  I  of 
this  specification,  paragraph  5.  Ihere  are  no  additional  or  specific  preparation  for  delivery 
requirements  tq>piicable  to  the  Visiud  System  module. 


6.  NOTES 

6.1.  Acronvm.s. 

ADST 

Advanced  Distributed  Simulation  Technology 

ANVIS 

Airborne  Night  Vision  System 

ARWA 

Advanced  Rotary  Wing  Aircraft 

BIU 

Bus  Interface  Unit 

CSCI 

Computer  Software  Configuration  Item 

CDRL 

Contract  Data  Requironent  List 

DdD 

Department  of  Defense 

DTV 

Di^  Thomal  Viewer 

DVO 

Direct  View  Optics 

EW 

Electronic  Warfare 

FDDI 


Hber-Distributed  Data  Int^ace 
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FUR 

FOV 

Foward-Lookiiig  Infrared 

RddrfView 

H 

HIDSS 

HWCI 

horizcmtal 

Helmet  Integrated  I^splay  Sight  System 
Hardware  Configuration  Item 

IG 

IHADS 

Image  Generator 

Integrated  Helmet  and  Display  Sight  System 

LjOD 

level-of-detail 

MFD 

ModSim 

Multifunction  Display 

Modular  Simulator 

NVG 

Night  Vision  Goggles 

OTW 

Out-the-window 

PNVS 

Pilot’s  Night  Vision  System 

ROM 

read-only  memory 

SAFOR 

Semi-automated  Forces 

TBD 

TIS 

TOD 

To  Be  Determined 

Thermal  hnaging  Sensor 

Time-of-day 

V 

VSC 

Vertical 

Visual  System  ControUo' 

